Management of the Evolution of Database-Centric Information Systems

Assume a database surrounded by a large variety of applications depending on it. For example, data entry or query forms are used by hundreds of users updating or querying information and complex workflows that operate in the enterprise frequently pose queries to the database. What happens if we delete a popular attribute from a relation in the database? Typically, all applications accessing this attribute will crash. Take for example, the case in Figure 1, where we use an Architecture-graph-like sketch representation of two relations (WORKS and EMP) and a query Q1. Observe the attribute EMP.Emp#, which is the Primary Key (PK) of relation EMP. Its role is such that it participates as (1) a grouper in the group-by query Q1, (2) a part of join condition between relations EMP and WORKS, (3) a part of the result of Q1, while, at the same time, (4) it is also part of a foreign key in the database. Clearly, the impact of deleting this attribute is significantly higher for the structure of the database and its surrounding applications, than, e.g., attribute WORKS.Hours. At the same, if for some reason we would like to alter the primary key of relation EMP, this would incur even higher reconstruction costs of the database (both due to the presence of query Q1 and the foreign key among relations WORKS and EMP).